
United States R\tent and TkADEMARK Office 



UNITED STATES DEPARTMENT OF COMMERCE 
United States Patent and Trademark OfHco 
Address: COMMISSIONER OF.PATENTS AND TRADEMARKS 
' Washington. D.C. 20231 
www . uspto. gov 



APPLICATION NO. 



HLING DATE 



FIRST NAMED INVENTOR 



ATTORNEY DOCKET NO. 



CONFIRMATION NO. 



09/305,331 



05/04/1999 



GEORGE VICTOR GUY AN 



10022/246-1 



1963 



28164 7590 12/20/2002 

BRINKS HOFER GILSON & LIONE 
POBOX 10395 
CHICAGO, IL 60610 



EXAMINER 



ROBERTSON, DAVID 



ART UNIT 



PAPER NUMBER 



3623 

DATE MAILED: 12/20/2002 



Please find below and/or attached an Office communication concerning this application or proceeding. 



PTO-90C (Rev. 07-01) 



Office Action Summary 



Application No. 

09/305,331 



Examiner 

Dave Robertson 



Applicant(s) 

GUYAN ET AL. 



Art Unit 

3623 



- The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 
Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified above is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and wrill expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 1 33). 

- Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1 .704(b). 

Status 

1 )K Responsive to comnnunication(s) filed on 21 November 2002 . 
2a)IEI This action is FINAL. 2b)D This action is non-final. 

3) n Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 1 1 . 453 O.G. 213. 
Disposition of Claims 

4) ^ Claim{s) 22-51 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) 0 Claim(s) is/are allowed;. 

6) 13 Claim{s) 22-51 is/are rejected. 
?)□ Claim(s) is/are objected to. 

8) 0 Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) n The specification is objected to by the Examiner. 

10) 0 The drawing(s) filed on is/are: a)n accepted or b)^ objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 

11) 0 The proposed drawing correction filed on is: a)n approved b)n disapproved by the Examiner. 

If approved, corrected drawings are required in reply to this Office action. 

12) 0 The oath or declaration is objected to by the Examiner. 
Priority under 35 U.S.C. §§119 and 120 

13) n Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 

a)nAII b)n Some*c)n None of: 

1 .□ Certified copies of the priority documents have been received. 

2. n Certified copies of the priority documents have been received in Application No. . 

3. n Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 

14) n Acknowledgment is made of a claim for domestic priority under 35 U.S.C. § 1 19(e) (to a provisional application). 

a) □ The translation of the foreign language provisional application has been received. 

15) 0 Acknowledgment is made of a claim for domestic priority under 35 U.S.C. §§ 120 and/or 121 . 
Attachment(s) 

1) □ Notice of References Cited (PTO-892) 4) □ Interview Summary (PTO-413) Paper No(s). . 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) 5) □ Notice of Infomial Patent Application (PTO-152) 

3) □ Infonnatlon Disclosure Statement(s) (PTO-1449) Paper No(s) . 6) □ Other: 
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DETAILED ACTION 



Response to Amendment 



1. 



This action is responsive to amendments filed 1 1/21/2002. Per applicant's request claim 



27 is amended; claims 22-51 are pending. 



2. 



Applicant has amended only claim 27 and in response to rejection under 1 12(2) over lack 



of antecedent basis. Applicant's amendment is sufficient to overcome the rejection. 



Claim Rejections - 35 USC § 102 



3. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States, 



4. Claims 22-51 are rejected under 35 U.S.C. 102(b) as being anticipated by Abbruzzese 
(US 5557515 A, 1996). 



The present invention claims an insurance database, a task database, and cUent/server 
arrangement for event-driven task processing using automation in the art of "workflow" systems 
with specific application to insurance claims processing. The particular mechanism for initiating 
tasks for claims processing relies on the occurrence of "events" described generally in the 
specification (pages 183-186) as events that have occurred in the life of various entities like 
claims. The specification teaches object-oriented component-based software theory, then defines 
the invention with block diagrams and conceptual, high-level fimctional descriptions of software 
components for enabling users to perform tasks related to claims processing. 
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Abbruzzese also discloses an event-driven workflow system for insurance claims 
processing in comprehensive detail, as compared to the present application disclosing no details 
of claims processing, teaching the essential operation of insurance claims processing in terms of 
activities performed by agents to resolve insurance claims. Abbruzzese description of the 
events driving the system through the tasks of insurance claims processing indicates its 
underlying functionality anticipates the present invention as broadly claimed. 

Specifically, as to claim 22, Abbruzzese teaches claims processing as a task performed by an 
insurance organization (column 1, lines 27-43), including: 

Claim Prior art teaches 

an insurance transaction database for Loss Claim database (column 3, lines 

storing information related to an insurance 37-43). 

transaction; 

a client component in communication with Operator accessing the local computer 
the insurance transaction database through a terminal (column 3, lines 44- 

configured for providing information 55). 
relating to the insurance transaction; 

and a server component in communication The local computer (column 3, lines 

with the client component, the transaction 44-55). 

database and the task library database, the 

server component including an event 

processor, a task engine and a task 

assistant; 

The task library database for storing rules for determining tasks to be completed upon an 
occurrence of an event is functionally equivalent to the series of input screens called Loan Processing 
Transactions (LPTX) in the prior art, whose presentation embodies "rules" for performing tasks related to 
each particular line of business subject to the claim (column 3, line 44, to column 4, line 44). Rules for 
determining tasks are inherent in the order and presentation of the input screens for each claims process. 
For example, Figure 1 shows at least one rule for determining the task "MAKE COPY", i.e., if the Notice 
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of Loss is not received in duplicate, then make a copy. The task library is the collection of these rules 
and screens that form the LPTX. 

Abbruzzese further discloses that the system is driven by events (see at least Fig. 32 and 
related text). Figure 16 and related text demonstrates at least how the LPTX are driven by the 
event of receiving incoming claim-related documents by fax, mail, or telephone report events. 
The event of document arriving triggers an appropriate task such as routing the document image 
to an appropriate queue for review by a supervisor (see Fig. 11) and subsequent routing to an 
agent at the client component (the remote terminal, see Fig. 5-6). In at least the manner 
described above, Abbruzzese teaches functionality inherent in performing the event-driven, 
insurance claims processing workflow as recited in the remaining limitations of claim 22, 



wherein the event processor is triggered by 
application events associated with a 
change in the information, and sends an 
event trigger to the task engine; 

wherein in response to the event trigger, 
the task engine identifies rules in the task 
library database associated with the event 
and applies the information to the 
identified rules to determine the tasks to be 
completed, and populates on a task 
assistant the determined tasks to be 
completed, 

wherein the task assistant transmits the 
determined tasks to the client component. 

As to claim 31, Abbruzzese teaches generating tasks for claim processing to be performed by 
an insurance organization (column 1, lines 27-43), including: 



namely: 



monitoring a transaction database 
containing information relating to an 
insurance transaction; 



See Loss Claim database (column 3, 
lines 37-43) and related text on 
accessing the insurance database. 
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The task library database for storing rules for determining tasks to be completed upon an 
occurrence of an event is functionally equivalent to the series of input screens called Loan Processing 
Transactions (LPTX) in the prior art, whose presentation embodies "rules" for performing tasks related to 
each particular line of business subject to the claim (column 3, line 44, to column 4, line 44). Rules for 
determining tasks are inherent in the order and presentation of the input screens for each claims process. 
For example, Figure 1 shows at least one mle for determining the task "MAKE COPY", i.e., if the Notice 
of Loss is not received in duplicate, then make a copy. The task library is the collection of these rules 
and screens that form the LPTX. 

Abbruzzese further discloses that the system is driven by events (see at least Fig. 32 and 
related text). Figure 16 and related text demonstrates at least how the LPTX are driven by the 
event of receiving incoming claim-related documents by fax, mail, or telephone report events. 
The event of document arriving triggers an appropriate task such as routing the document image 
to an appropriate queue for review by a supervisor (see Fig. 1 1) and subsequent routing to an 
agent at the client component (the remote terminal, see Fig. 5-6). In at least the manner 
described above, Abbruzzese teaches functionality inherent in performing the event-driven, 
insurance claims processing workflow as recited in the limitations of claim 31, namely: 

in response to certain changes in the 



information, identifying an event 
associated with the change; 

in response to the identified event, 
retrieving rules stored in a rules database, 
said retrieved rules being associated with 
said identified event; 

determining a task to be completed based 
on said retrieved rules and on the 



information; 



and finally, Abbruzzese discloses: 
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assigning said task to an employee or 
group of employees for completions- 
displaying information associated with 
said task on a user interface; 



See Supervisor assigns task to "handler' 
(see at least column 1, lines 37-38) 

See at least Tables IV to XX showing 
user interface display and entry of 
information relating to claims 
processing tasks. 



capturing data entered through the user 
interface and storing said data in said 
transaction database; 



and identifying said task as completed. 



See at least column 2, Hnes 9-15 
completion of work on the claim (task). 



As to claim 36, Abbruzzese teaches generating tasks for claim processing to be performed by 
an insurance organization (column 1, lines 27-43), including: 



The task library database for storing rules for determining tasks to be completed upon an 
occurrence of an event is functionally equivalent to the series of input screens called Loan Processing 
Transactions (LPTX) in the prior art, whose presentation embodies "rules" for performing tasks related to 
each particular line of business subject to the claim (column 3, line 44, to column 4, line 44). Rules for 
determining tasks are inherent in the order and presentation of the input screens for each claims process. 
For example, Figure 1 shows at least one rule for determining the task "MAKE COPY", i.e., if the Notice 
of Loss is not received in duplicate, then make a copy. The task library is the collection of these rules 
and screens that form the LPTX. 

Abbruzzese further discloses that the system is driven by events (see at least Fig. 32 and 
related text). Figure 16 and related text demonstrates at least how the LPTX are driven by the 



transmitting information related to an 
insurance transaction; 



See electronically routing images to a 
staff member, OCR'ing the images to 
the insurance information database, and 
transmitting information via LPTX 
screens (column 3). 



determining characteristics of the 
information related to the insurance 
transaction; 



See column 4, lines 6-19) discovering 
of type of claim, property, information 
about insured, etc. 



Application/Control Number: 09/305,331 
Art Unit: 3623 



Page? 



event of receiving incoming claim-related documents by fax, mail, or telephone report events. 
The event of document arriving triggers an appropriate task such as routing the document image 
to an appropriate queue for review by a supervisor (see Fig. 11) and subsequent routing to an 
agent at the client component (the remote terminal, see Fig. 5-6). hi at least the manner 
described above, Abbnizzese teaches functionality inherent in performing the event-driven, 
insurance claims processing workflov^ as recited in the limitations of claim 36, namely: 



applying the characteristics of the 
information related to the insurance 
transaction to rules to determine a task to 
be completed; 

transmitting the determined task to a task 
assistant, 

wherein the task assistant displays the 
determined task; 

allowing an authorized user to edit and 
perform the determined task and to update 
the information related to the insurance 
transaction in accordance with the 
determined task; 

and finally, Abbruzzese discloses: 

storing the updated information related to 
the insurance transaction; 

and generating a historical record of the 
completed task. 



Stored to the Loss Claim database 
(column 3, lines 37-44). 

See Activity Log (column 4, lines 58- 
67), an historical record of activity 
(tasks). 



As to claims 24, 27 and 37, Abbruzzese discloses work management of insurance claims 
processing that would necessarily be determined by "characteristics" governed by regulation, 
account servicing commitments, and best practices in insurance claim processing, and one skilled 
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in the art would have recognized such characteristics as inherent to the design of an insurance 
claims processing system of which Abbruzzese is exemplary. The library of tasks thus consists 
of a "standardized" list of tasks based on these "characteristics". 

As to claim 25, Abbruzzese discloses task due dates (column 4, lines 46-57). 

As to claim 26, Abbruzzese discloses an historical record of activity (see Activity Log 
(column 4, lines 58-67). 

As to claims 28, 29, 38 and 43-50, Abbruzzese discloses collection of specific 
information on the policy, the claim, the participant (insured), and line of property (see Tables IV 
to XX). These are the levels described by the specification as different groups of information 
collected for claims processing. Abbruzzese discloses a "claim folder" as the collection of 
information on a claim in the Loss Claim database. 

As to claims 30, 34 and 39, Abbruzzese discloses information related to the insurance 
transaction is a claim under an insurance policy (see Backgroimd). Claims under an insurance 
policy are inherently claims for a compensation. 

As to claim 32, Abbruzzese teaches completion of work on the claim task must result in 
an indication in the insurance claim database (column 2, lines 9-15). Abbruzzese also teaches 
that "Once an LPTX has been completed it cannot be altered." Storing in the "transaction 
database" that a claim processing task has been completed is inherent to the functioning of the 
system. 

As to claims 40-42, Abbruzzese discloses different lines of insurance, i.e. workmen's 
comp, automobile, property/liability, etc. (column 3, lines 59-64) and LPTX screens to collect 
information particular to each. 
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As to claims 23, 33, 35 and 51, Abbruzzese discloses a task library database for storing 
rules for determining tasks to be completed upon an occurrence of an event is functionally equivalent to 
the series of input screens called Loan Processing Transactions (LPTX) in the prior art, whose 
presentation embodies "rules" for performing tasks related to each particular line of business subject to 
the claim (column 3, line 44, to column 4, line 44). To prepare such LPTX screens requires the use an 
interface for entering the rules for determining tasks and the order and presentation of the LPTX input 
screens for each claims process. Thus, claim 5 1 is present in Abbruzzese in at least the programmer 's 
interface for creating the LPTX screens. 



5. Applicant's arguments filed 1 1/21/2002 have been fully considered but they are not 
persuasive. All claims stand rejected over grounds of the previous office action. 

6. Apphcant traverses Examiner's objection to the jumbo specification. In view of 
Applicant's expressed willingness to review the specification at allowance, this objection is 
withdrawn. 

7. Applicant traverses rejection of claims 33 and 51 under 35 U.S.C. 1 12, first paragraph, as 
lacking enablement in the specification. Applicant's argument is persuasive and the rejection is 
withdrawn. 

Applicant directs attention to two passages in the specification that together indicate an 
interface, the Task Assistant, which provides a "library rules interface" (page 181, lines 10-16) 
which allows task librarians to define tasks and rules that create them (page 184, lines 5-10). 
These are sufficient showing that the original specification contemplated a library rules interface 
that allows task librarians to edit rules. 



Response to Arguments 
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8. Applicant traverses rejection of claims 22-51 under 35 U.S.C. 102(b) as anticipated by 
Abbruzzese et al. Applicant's arguments are non-persuasive and the claims stand rejected. 

Applicant argues that the LPTX screen disclosed in Abbruzzese is not functionally 
equivalent to the task library database as claimed in the present invention. Applicant argues that 
the LPTX screen is "generated from fixed software code", and that the LPTX screen "does not 
apply claim information to an identified rule" (Remarks, pages 6-7). However, as described in 
the office action, it is the series of LPTX screens, a collection of screens implementing rules for 
carrying out claims processing, that is functionally equivalent to the task library database. The 
LPTX screens inherently implement rules dependent on the entered claim information, the series 
of screens is not fixed, but rather vary according to claim input, for example, the type of claim 
being made. 

As to the rules guiding the LPTX screens being "generated from fixed software code", 
programmers creating the series of LPTX screens is equivalent to Applicant's "specialists who 
understand the complexity of the rules involved" (Specification, page 184, line 8). Specialists 
enter rules, programmers enter code, each resulting in the equivalent of a task library database 
for storing rules as claimed by the present invention. The programmer's interface, inherent to 
Abbruzzese, and a task library administrator's interface are functionally equivalent, and 
therefore Abbruzzese anticipates the invention as claimed. 

As to lists of standardized tasks, argued as lacking in Abbruzzese, the series of LPTX is 
itself a list, presented one screen at a time, of tasks to be performed for claims processing. 

As to marine claims, argued as lacking in Abbruzzese, a yacht is property and 
Abbruzzese discloses property/liability claims. Specifying of marine as a type of claim amounts 
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to the recitation of non- functional data; the type of claim has no bearing on the invention as 
claimed, and thus carries no patentable weight. 

As to negotiation of the claim payment, argued as lacking in Abbruzzese, Applicant fails 
to claim the specific details of negotiation argued to be lacking in Abbruzzese. 



9. THIS ACTION IS MADE FINAL. AppUcant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS fi-om the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated fi-om the mailing date of the advisory action. Li no event, 
however, will the statutory period for reply expire later than SIX MONTHS fi-om the mailing 
date of this final action. 



Conclusion 



THIS SECTION INTENTIONALLY BLANK 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Dave Robertson whose telephone number is (703) 306-5679. 
The examiner can normally be reached Mon 12:30p-8:30p T-Th 8:30a-8:30p Fri 8:30a-12:30p:. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tariq Hafiz can be reached on (703) 305-9643. 

Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the Receptionist at telephone number (703) 308-1113. 

Any response to this action should be mailed to: 



(703) 308-7687 [Official communications] 

(703) 308-7687 [After Final communications, labeled "Box AF"] 

(703) 746-5552 [Informal/draft communications, directly to Examiner, 

labeled "PROPOSED " or "DRAFT"] 
Hand delivered responses should be brought to Crystal Park 5, 2451 Crystal Drive, 
ArUngton, VA, 7th floor receptionist. 
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December 17, 2002 
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